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HIERARCHICAL  COROUTINES 


A  MECHANISM  FOR  IMPROVED  PROGRAM  STRUCTURE 


Ab  strac  t 


The  design  of  a  built-in  coroutine  mechanism  for  a 
procedural  language  is  described.  This  mechanism  allows  the 
simultaneous  activation  of  coroutines  and  recursive  procedures 
and  permits  coroutines  to  have  value  or  reference  parameters.  It 
is  argued  that  this  design  has  clearer  semantics  than  the 
traditional  view  of  coroutines  (particularly  in  the  presence  of 
recursion)  while  retaining  the  feature  that  makes  coroutines 
useful  --  the  ability  to  leave  a  coroutine  without  destroying  its 
internal  state.  The  inclusion  of  parameters  in  coroutine  calls 
has  rarely  been  attempted.  The  problems  encountered  in  creating 
type-safe  and  well  defined  parameters  are  discussed  and  a 
solution  is  outlined. 
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HIERARCHICAL  COROUTINES: 


A  MECHANISM  FOR  IMPROVED  PROGRAM  STRUCTURE 


1'  Introduction 

The  concept  of  coroutines  [4,18]  has  been  known  for  quite  a 
while,  and  many  applications  have  been  discussed  for  them  [8,133* 
However,  with  the  exception  of  some  simulation  languages  such  as 
SIMULA  [6,53  and  implementation  languages  such  as  BLISS  [223, 
most  languages  lack  built-in  coroutine  facilities.  Consequently, 
other  language  primitives  are  used  to  simulate  the  coroutine 
control  structure. 

One  reason  for  this  omission  in  the  design  of  common 
sequential  programming  languages  is  undoubtedly  the  fact  that  it 
is  difficult  to  reconcile  recursive  procedure  calls  or  a  dynamic 
stack  of  activation  records  with  coroutine  calls.  Since  goto's 
together  with  static  or  global  variables  can  be  used  to  provide  a 
straightforward  simulation  of  coroutines,  it  was  easier  to  leave 
out  coroutines  and  include  recursion. 

Now,  however,  the  goto  has  fallen  into  disrepute.  Several 
programming  languages  lack  them  altogether  (e.g.,  Euclid  [16], 
SP/k  [123)  and  others  have  made  them  awkward  to  use  (e.g.,  Pascal 
[14]).  Besides  this,  many  users  of  languages  possessing  goto's 
refuse  to  use  such  an  unstructured  language  feature.  To  use  high 
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of  control.  As  a  consequence  of  this  decomposition  of  the 
calling  action,  the  language  is  able  to  remove  all  distinctions 
between  coroutines  and  recursive  procedures.  A  procedure  is 
recursive  if  a  new  activation  record  is  created  before  control  is 
transferred  to  it,  and  it  is  a  coroutine  if  a  new  activation 
record  is  not  created.  Also,  it  is  possible  to  resume  execution 
of  a  coroutine  with  or  without  first  rebinding  its  parameters. 

The  price  paid  for  this  uniformity  and  flexibility  is  that 
SL5  is  a  complicated  language  and  permits  the  writing  of  very 
poorly  structured  programs.  Even  its  creators  admit  that  "many  of 
the  features  of  SL5  are  esoteric,  and  the  generality  of  the 
implementation  necessary  to  support  research  applications  makes 
SL5  inappropriate  for  general-purpose  use"  [73.  Hence,  although 
SL5  has  the  most  general  solution  to  the  mating  of  coroutines  and 
recursive  procedures,  we  shall  present  a  more  restrictive  but 
better  disciplined  approach. 

A  more  structured  form  of  coroutine  has  been  devised  by 
Clint  [3]  as  a  preliminary  part  of  (significantly)  a  paper 
describing  correctness  proving  techniques  for  coroutines. 
Clint's  design  is  quite  similar  in  some  ways  to  the  hierarchical 
coroutines  which  we  shall  describe. 

In  section  2  we  summarize  the  motivation  for  using 
coroutines  and  the  criteria  we  would  like  a  coroutine 
implementation  to  satisfy.  Section  3  then  shows  why  conventional 
implementations  do  not  live  up  to  our  requirements,  so  in  section 
4  we  introduce  hierachical  coroutines  as  a  more  satisfactory 
alternative . 

Section  5  addresses  itself  to  the  reconciliation  of 
coroutines  and  recursion  and  section  6  outlines  some  improvements 
to  the  user  interface. 

In  section  7  we  discuss  the  problem  encountered  in  providing 
coroutines  with  a  parameter  mechanism  and  develop  a  solution. 
After  a  brief  discussion  of  function  coroutines  in  section  8  we 
conclude  with  a  proposed  storage  management  scheme  for  handling 
coroutines . 


2.  What  is  a  Coroutine? 

The  traditional  view  of  coroutines  distinguishes  them  from 
subroutines  by  virtue  of  there  not  being  any  hierarchical 
relationship  between  coroutines.  With  these  symmetric 
coroutines,  each  coroutine  calls  the  other(s)  as  if  it  were  the 
main  program  and  the  others  its  subroutines.  This  is  the  form  of 
coroutine  which  is  facilitated  by  BLISS,  SIMl  -A67,  and  SL5. 
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Why  is  this  arrangement  of  having  all  transfers  via  a  "call" 
(or  "resume")  statement  preferable  to  using  returns?  Most 
significantly,  this  permits  each  coroutine  to  resume  execution 
from  the  point  where  it  previously  left  off,  and  thereby  preserve 
its  state.  The  fact  that  a  symmetric  coroutine  has  the  ability 
to  name  its  successor  is  both  less  important  and,  it  can  be 
argued,  undesirable.  If  this  freedom  is  granted,  it  is  possible 
to  create  coroutine  transfer  paths  that  have  unstructured 
properties  similar  to  those  resulting  from  the  misuse  of  goto's. 

There  is,  however,  an  alternative  to  symmetric  coroutines. 
That  is  what  we  shall  call  hierarchical  coroutines .  The  idea  of 
hierarchical  coroutines  cornes  from  the  observation  that  a  calling 
procedure  in  a  regular  subroutine  environment  already  has  the 
property  that  it  preserves  its  state  after  calling  a  subroutine. 
It  only  remains,  therefore,  to  provide  the  subroutine  with  a 
mechanism  other  than  return  for  transferring  control  back  to  the 
caller  and  still  preserve  its  state. 

This  mechanism  is  provided  by  the  " suspend"  statement.  When 
a  coroutine  suspends  itself  it  saves  its  state  and,  rather  than 
transfer  control  explicitly  to  a  specific  coroutine,  returns 
control  implicitly  to  its  caller.  The  "suspend"  statement 
transfers  control  to  the  same  place  in  the  caller  as  normal 
termination  of  the  coroutine,  so  from  the  caller's  point  of  view 
the  two  ways  of  leaving  the  coroutine  are  indistinguishable. 
Also,  coroutines  and  ordinary  procedures  are  indistinguishable  to 
the  caller  since  both  return  control  to  the  calling  point. 

Note  that  with  hierarchical  coroutines  it  makes  sense  to 
talk  about  a  single  coroutine  since  the  role  of  one  of  the 
coroutines  in  the  symmetrical  scheme  is  assumed  by  a  non¬ 
coroutine  calling  procedure  in  the  hierarchical  scheme. 

The  criteria  we  would  like  to  have  a  coroutine 

implementation  satisfy  are: 

1.  A  calling  routine  should  not  need  to  know  whether  the 
routine  being  called  is  a  coroutine  or  not.  In  addition,  it 
should  not  distinguish  between  initial  coroutine  invocations 
and  calls  to  resume  execution  of  coroutines. 

2.  Programs  not  requiring  the  use  of  coroutines  should  not 
suffer  any  degradation  in  performance  due  to  the  overhead  of 
supporting  coroutines. 

3.  The  syntax  and  semantics  of  the  features  for  making  use  of 
coroutines  should  facilitate  and  encourage  the  creation  of 
programs  with  clear  control  flow  structures.  Coroutines 
should  be  natural  constructs  which  are  no  more  complicated 
to  use  than  normal  procedures. 
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3_.  Deficiencies  of  Symmetric  Coroutines 

Several  examples  will  be  used  to  illustrate  applications  of 
coroutines.  The  first  example  is  the  one  which  motivated  Conway 
to  invent  the  concept  of  coroutines.  The  various  phases  of  a 
compiler  are  viewed  as  coroutines  accepting  input  from  previous 
phases  and  transmitting  output  to  subsequent  phases.  Thus,  the 
scanner  (SCAN)  calls  the  parser  (PARSE)  every  time  it  recognizes 
a  token;  the  parser  calls  the  scanner  when  it  requires  the  next 
token  and  calls  the  code  generator  (EMIT)  when  it  completes  the 
recognition  of  a  syntactic  construct;  and  the  code  generator 
treats  the  parser  as  a  subroutine  directing  it  to  emit  the 
sequences  of  code  indicated  by  the  values  passed  back  through 
some  parameters.  Conceptually,  we  have  a  pipeline  or  pipe  [19] 
of  programs  which  process  data  as  it  flows  from  one  routine  to 
the  next.  Figure  3*1  illustrates  this  model  of  a  compiler. 


source  !  !  i  !  I  !  object 

SCANNER  | - >  |  PARSER  1 - - >  |  EMITTER  J— —  —  > 

program!  ! tokens!  [parameters!  !  code 


Figure  3*1.  Coroutines  in  a  Compiler 

The  symmetric  coroutine  implementation  of  the  compiler 
example  would  require  each  coroutine  to  know  both  its  predecessor 
and  its  successor.  For  example,  the  parser  might  contain  the 
loop  in  figure  3.2.  The  scanner  and  code  generator  return 
control  to  the  parser,  however,  not  by  means  of  a  return 

statement  but  by  themselves  calling  the  parser  with, 

respectively,  the  calls  PARSE(TOKEN)  and  PARSE(CODE). 

while  not  END  OF  INPUT  do  begin 


EMIT(CODE);  {send  CODE  to  the  code  generator} 


SCAN(TOKEN)  {get  next  token  from  the  scanner} 

end 


Figure  3.2.  Part  of  a  Symmetric  Parse  Coroutine 
But  is  it  really  necessary  for  each  coroutine  to  know  its 
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predecessor  and  successor?  Strictly  speaking,  it  is  not 
necessary  for  the  parser  to  know  either  its  successor  or  its 
predecessor.  It  could  treat  the  call  to  SCAN  as  an  input 
operation  and  the  EMIT  call  as  a  write.  This  is  the  approach 
taken  in  a  UNIX  pipe.  These  pipes  are  available  both  within 
programs  (in  their  full  generality)  and  at  the  operating  system 
command  level  (with  a  shell  [193  syntax  which  permits  the 
creation  of  linear  pipelines  only.) 

By  the  nature  of  the  UNIX  file  system  pipes  can  transmit 
only  one  datatype  --  characters,  but  it  is  possible  to  generalize 
the  pipe  concept  to  other  datatypes.  Despite  their  elegance, 
pipes  may  permit  poor  program  control  structure  and  may  require 
more  overhead  than  is  necessary  since  they  require  the  operating 
system  to  provide  the  linkage  between  coroutines.  Moreover, 
unless  restrictions  are  placed  on  the  number  of  readers  or 
writers  one  pipe  (or  channel)  can  have,  nondeterministic 
behaviour  can  occur!  With  these  restrictions  imposed,  specifying 
a  pipe  is  equivalent  to  naming  a  successor  except  that  the  pipe 
names  the  successor  indirectly  rather  than  directly. 

The  linear  pipelines  created  by  the  shell  do  not  have  these 
disadvantages,  but  they  are  not  sufficiently  flexible.  For 
example,  the  tree  merge,  which  will  be  presented  later,  cannot  be 
accomplished  with  a  linear  pipeline  because  it  requires  the 
merging  of  two  output  streams  into  a  single  process. 

Symmetric  coroutines  (of  which  pipes  are  a  special  case)  are 
not  sufficiently  restrictive.  Because  they  lack  any  structure- 
enforcing  constructs  they  permit  the  creation  of  convoluted 
control  flow  every  bit  as  bad  as  can  be  achieved  with  goto’s. 
For  example,  consider  the  three  symmetric  coroutines  in  figure 
3.3. 


coroutine  A  +->coroutine  B  +->coroutine  C 

II  II  I 

II  II  I 

v  i  vi  v 

resume  B  — +  resume  C  --  +  resume  B 

:  / 

;  <-  — - / 

end 
/  \ 

/  ?  \ 

Figure  3*3.  Control  Flow  Problems  with  Symmetric  Coroutines 

After  B  terminates,  where  does  execution  resume?  Two 
choices  are  possible.  B  can  return  either  to  the  return  (resume) 
point  in  the  coroutine  which  initially  called  B  (i.e.,  A),  or  to 
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the  resume  point  in  the  coroutine  which  most  recently  called  B 
(  i  .e  .  ,  C)  . 

The  latter  choice  leads  to  an  immediate  problem  when  C 
terminates.  By  either  rule  C  must  return  to  B,  but  B  no  longer 
exists  because  it  has  already  terminated.  The  other  choice  (B 
returns  to  A)  is  the  only  feasible  choice,  but  even  it  has  some 
f 1 aws . 

When  A  regains  control,  what  happens  to  C?  Should  C  be 
terminated  or  should  it  remain  active?  Examples  exist  to  support 
either  choice.  If  A,  B,  and  C  are  our  three  compiler  phases, 
then  the  termination  of  the  parser  after  regaining  control  from 
the  code  generator  should  imply  termination  of  the  entire 
compiling  procedure  and  both  the  scanner  (A)  and  the  code 
generator  (C)  should  terminate. 

On  the  other  hand,  if  C  is  a  random  number  generator,  which 
might  be  called  by  A  independently  from  the  call  by  B,  it  should 
not  terminate  when  B  terminates.  By  the  way,  random  number 
generators  (or  permutation  generators)  are  excellent  applications 
for  coroutines  because  they  are  required  to  remember  their 
previous  return  value. 

Thus,  we  see  that  symmetric  coroutines  do  not  describe 
clearly  the  control  flow  logic  of  the  program  containing  them  and 
thereby  violate  the  third  of  the  three  design  principles. 

In  addition,  the  first  design  principle  is  violated  by 
existing  implementations  of  symmetric  coroutines.  These 
implementations  [22,5,9]  decompose  the  calling  action  into  at 
least  2  parts:  activation  of  a  routine  (i.e.,  allocating  storage) 
and  transfer  of  control.  If  both  of  these  actions  take  place,  a 
new  procedure  (or  coroutine)  is  called.  If  only  the  second  is 
carried  out  a  formerly  activated  coroutine  is  resumed. 

This  situation  is  not  an  inherent  requirement  of  symmetric 
coroutines  but  it  does  seem  to  go  well  with  the  low  level 
flexibility  of  symmetric  coroutines. 


4_.  Hierarchical  Coroutines 

Hierarchical  (called  semi- symmetric  in  [20])  coroutines  give 
the  programmer  control  over  the  termination  of  routines  such  as  C 
in  figure  3.3  by  using  static  nesting  to  indicate  dependence  of 
one  coroutine  on  another.  When  a  coroutine  executes  a  "suspend" 
statement  its  state  is  preserved  but  control  passes  to  the  return 
point  of  the  coroutine  or  procedure  which  most  recently  called 
it.  When  it  is  subsequently  called  again  it  resumes  execution  at 
the  point  following  the  "suspend"  using  the  preserved  local 
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environment.  For  languages  having  an  explicit  "return" 
statement,  the  usage  of  the  "suspend"  statement  is  the  same  as 
the  usage  of  "return";  this  helps  to  avoid  confusion  when  writing 
coroutines . 

An  implementation  of  the  compiler  using  hierarchical 
coroutines  can  use  any  of  the  three  phases  as  the  main  procedure. 
We  first  illustrate  by  choosing  PARSE  to  be  the  main  program. 
This  is  shown  in  figure  4.1. 

In  figure  4.2,  the  phases  are  organized  differently,  with 
each  phase  declared  within  its  predecessor  in  order  to  reduce  the 
scope  of  each  routine  to  a  minimum.  The  only  legal  calls  are 
calls  to  immediate  successors  because  enclosing  coroutines  cannot 
be  invoked  recursively.  By  this  organization  we  can  avoid  the 
situation  in  figure  4.1  wherein  EMIT  and  SCAN  can  legally  call 
each  other,  but  logically  should  not. 

With  the  nestings  used  in  figure  4.1,  SCAN  and  EMIT  are 
unrelated  to  each  other  but  are  coroutines  of  PARSE.  They 
communicate  with  PARSE  via  their  parameters,  are  called  by  PARSE, 
and  return  control  to  PARSE  whenever  they  suspend  themselves  or 
terminate.  When  PARSE  terminates,  if  either  of  SCAN  and  EMIT  is 
still  active  (but  suspended),  it  is  also  terminated  because  it  is 
textually  enclosed  in  PARSE.  Wang  and  Dahl  [20]  have  used  the 
property  that  all  active  coroutines  declared  within  a  terminating 
routine  must  also  be  terminated  to  prove  the  we  1 1- behav ed ne ss  of 
a  set  of  coroutines. 

Note  that  although  PARSE  is  declared  to  be  a  coroutine,  it 
never  suspends  itself  and  is,  therefore,  equivalent  to  an 
ordinary  subroutine.  We  make  it  a  coroutine  in  order  to  conform 
to  the  convention  that  coroutines  cannot  be  nested  within 
(possibly  recursive)  procedures  although  they  may  contain 
procedures.  This  convention,  which  is  followed  by  PISA  [17], 
guarantees  the  uniqueness  of  coroutine  activations  and  implies 
that  the  main  program  must  be  a  coroutine  (if  any  other 
coroutines  are  to  be  declared  within  it.) 

Similar  remarks  apply  to  the  organization  in  figure  4.2. 
However,  in  this  case  the  termination  of  PARSE  will  cause  the 
termination  of  EMIT  while  if  SCAN  terminates,  it  will  also  cause 
PARSE  and  EMIT  to  terminate  if  they  have  not  already  done  so. 
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coroutine  PARSE; 


coroutine  SCANCvar  TOKEN:  tokentype); 

STATE  :=  0; 

C  :=  N  EXT CHAR ; 

while  not  EOF  do  begin 

T  :=  SCANTABCSTATE, C) ; 


• 

TOKEN  : =  ... 

suspend;  {transmit  TOKEN  to  PARSE} 

STATE  :=  0; 

C  :=  NEXT CHAR 

end ; 

TOKEN  :=  ENDMARK 

ena ; 


coroutine  EMITCX:  code  tempi  ate) ; 


while  TRUE  do  begin 
{emit  code} 

suspend  {await  further  instructions} 

end 

end ; 


SCAN (T  ) ; 

while  T  i  ENDMARK  do  begin 


EMIT (  .  .  .)  ; 


SCAN (T  ) 

end 

end 


Figure  4.1. 


Hierarchical  Coroutines 
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coroutine  SCAN; 

coroutine  PARSECTOKEN:  tokentype); 
coroutine  EMITCX:  code  template); 


• 

while  TRUE  do  begin 
{emit  code} 
suspend 

end 

end;  {end  of  EMIT} 


while  TOKEN  i  ENDMARK  do  begin 


EMITC . . .) ; 


suspend 

end ; 


end;  {end  of  PARSE} 


STATE  :=  0; 

C  : =  N  EXT CHAR ; 

while  not  EOF  do  begin 

T  : =  SCANTABC  STATE , C) ; 


PARSEC . . .)  ; 


end ; 

end 


{end  of  SCAN} 


Figure  4.2 


Nested  Hierarchical  Coroutines 
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5.  Recursion  and  Coroutines 
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conceptual  convenience.  This  algorithm 
express  in  any  other  way.  The  problem  is 


more  than 
would  be 

-<v ^  ....  - -  — j.  .....  K.  ...........  to  merge 

tained  in  the  nodes  of  two  binary  search  trees  into  a 
r  list.  Here,  the  main  program  calls  one  of  two 
TRAV1  and  TRAV2,  each  time  it  needs_the  contents  of 
e  in 

"  re  t  ur  n" 
re  in  the 


,  respectively,  tree  T1  and  tree  T2.  TRAV1  and 
a  result  to  the  main  program  while  keeping 
they  are. 


tr av  ersal 


This  example  illustrates  how  coroutines  and  recursion  can  be 
used  simultaneously.  The  requirement  that  initial  coroutine 
calls,  resumes  of  coroutines,  and  procedure  calls  be 
indistinguishable  from  the  calling  program  forces  on  us  the 
restriction  that  coroutines  not  invoke  themselves  recursively. 
However,  a  coroutine  may  contain  declarations  of  recursive 
procedures.  Naturally,  these  procedures  can  only  be  called  from 
within  the  coroutine  in  which  they  are  declared. 


To  give  meaning  to  the 
specify  how  we  are  to  inter 
within  a  procedure.  The  effec 
defined  to  be  the  suspension 
along  with  all  procedure  activ 
In  the  next  section  we  shall 
to  generalize  this  definition 
need  not  enclose  the  procedure 


following  program  we  must  first 
pret  a  "suspend”  statement  occuring 
t  of  such  a  "suspend"  statement  is 
of  the  closest  enclosing  coroutine 
ations  created  by  the  coroutine. 

discuss  the  consequences  of  trying 
so  that  the  coroutine  suspended 


Coroutine  TRAVi  (for  i  =  1  or  i  =  2)  is  shown  in  figure  5.1. 
It  contains  the  nested  recursive  procedure  TRAVERSE.  TRAVi  is 
suspended  via  a  suspend  statement  within  TRAVERSE.  Hence,  the 
coroutine  is  suspended  along  with  all  current  activations  of  the 
recursive  procedure. 

Coroutines  TRAVI  and  TRAV2  are  called  by  a  procedure  (or 
coroutine)  MERGE,  such  as  given  in  figure  5.2.  TRAVI  and  TRAV2 
could  be  declared  either  within  MERGE  (in  which  case  MERGE  must 
be  a  coroutine)  or  in  the  scope  of  a  coroutine  containing  MERGE. 
Since  they  are  guaranteed  to  terminate  before  MERGE,  there  is  no 
need  for  them  to  be  nested  in  MERGE. 


coroutine  TRAVi(var  N:  TNODE;  ROOT:  TNODE); 
procedure  TRAVERSE(T:  TNODE); 
beg  in 

if  TT.LSON  i  nil  then  TRAVERSE (T 7 . LSON ) ; 

N  :=  T; 
suspend ; 

if  TT.RSON  i  nil  then  TRAVERSE (T7 . RSON ) 

end ; 
begin 

TRAVERSE (ROOT ) ; 

N  : =  nil 

end 

Figure  5.1.  Coroutine  for  Recursive  Traversal 


procedure  MERGECT1,  T 2:  TNODE); 
var  N 1 ,  N2:  TNODE; 
beg  in 

TRAV1 (N 1 ,T1 ); 

TRAV2CN2, T2) ; 

while  C N 1  i  nil)  and  (N2  i  nil)  do 

if  NIT. DATA  <  N 27 • DATA  then  begin 
wr ite( N 1 7 • DATA ) ; 

TRAV1 ( N 1 , T 1 ) 

end 

else  begin 

write(N2T .DATA); 

TRAV2CN2, T2) 
end ; 

while  N1  i  nil  do  begin 
wr ite( N 1 7 . DATA  ) ; 

TRAV1 (N 1 , T 1 ) 

end ; 

while  N2  i  nil  do  begin 
write(N2T .DATA); 

TRAV2CN2, T2) 

end 

end 


Figure  5.2.  MERGE  Procedure  Using  Coroutines 


1  2 


6.  Avoiding  the  Duplication  of  Code  in  Several  Coroutines 


Let  us  now  consider  the  recursive  procedure  TRAVERSE.  It  is 
defined  twice,  once  within  each  of  the  two  identical  coroutines. 
One  way  to  avoid  tnis  is  to  have  both  coroutines  make  use  of  the 
same  procedure  by  putting  the  declaration  outside  of  the 
coroutines  in  the  enclosing  coroutine  (the  main  program  or  the 
MERGE  routine.)  Now  the  coroutine  suspended  by  the  procedure  is 
determined  by  following  the  dynamic  chain  rather  than  the  static 
chain  of  activations. 

This  solution  has  the  advantages  that  it  requires  no 
extensions  to  the  syntax  of  the  host  language  (other  than  the 
keywords  "coroutine"  and  "suspend")  and  it  makes  coroutine  and 
procedure  calls  completely  analogous.  However,  there  are  also 
some  disadvantages. 

One  disadvantage  is  that  the  semantics  of  a  "suspend"  which 
is  not  located  within  a  coroutine  are  not  well  defined.  If 
TRAVERSE,  for  example,  is  not  called  by  TRAV1  or  TRAV2  the  only 
coroutine  available  to  be  suspended  is  the  main  program,  so  some 
arbitrary  i nterpretat ion  must  be  defined  for  the  suspension  of  a 
main  program.  PISA  [173  does  make  such  an  interpretation. 

In  addition,  allowing  a  procedure  to  suspend  a  coroutine  in 
which  the  procedure  is  not  nested  can  lead  to  confusing  flow  of 
control.  For  example,  in  figure  6.1,  execution  following  the 
"suspend"  in  P  might  be  resumed  at  any  of  the  indicated  points. 
These  resume  points  are  not  the  statements  following  calls  to  P 
(as  would  be  the  case  if  P  simply  returned)  but  follow  calls  to 
the  most  recently  executed  coroutine  in  any  sequence  of  calls 
leading  to  a  call  to  P.  Any  number  of  procedures  or  recursive 
calls  could  have  come  between  the  coroutine  and  P,  and  someone 
reading  the  program  would  have  to  trace  through  all  those  calls 
to  find  where  a  "suspend"  in  P  could  lead. 

A  solution  which  has  the  opposing  advantages  and 
disadvantages  is  arrived  at  by  first  restricting  procedures  to 
being  able  to  suspend  only  their  textually  enclosing  coroutine. 
Then,  rather  than  have  identical  coroutines  share  a  common 
procedure,  we  enable  the  user  to  describe  all  of  the  identical 
coroutines  with  a  single  "coroutine  class"  declaration. 
Subsequently,  each  coroutine  is  declared  by  means  of  a  "coroutine 
instance"  declaration  which  associates  a  unique  coroutine  name 
with  the  description  given  in  a  class  declaration.  These  class 
and  instance  declarations  are  similar  to  a  special  case  of  the 
SIMULA  class  declaration  and  "new"  operation  except  that  they  are 
strictly  compile-time  features.  As  such,  a  coroutine  class 
declaration  is  essentially  a  procedural  version  of  a  Pascal  type 
ieclaration  and  the  instance  declaration  is  a  regular  procedure 
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declaration  which  makes  use  of  a  previously  defined  class. 
Figure  6.2  shows  how  this  mechanism  could  be  used  to  define  TRAV1 
and  TRAV2 . 

Enhancements  to  the  class  and  instance  declarations  could 
add  compile-time  parameters.  This  would  make  the  class 
declaration  essentially  a  specialized  macro  definition. 


procedure  P; 

suspend ; 

end ; 

coroutine  Cl ; 

procedure  Q 

call  P; 

end ; 

coroutine  C 2 ; 
call  P; 

end ; 

call  C 2 ; 

• 

.  {resume  here  if  C2  calls  P} 

• 

call  Q 

end ; 

coroutine  C3; 

• 

call  P; 


end ; 

call  Cl; 

.  {resume  here  if  Cl  calls  Q  which  calls  P} 


call 


C3; 


{resume  here  if  C3  calls  P} 


Figure  6.1.  Control  Flow  in  which  a  Non-Enclosed  Procedure 

Suspends  its  Caller 
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coroutine  class  TRAV(var  N:  7N0DE;  ROOT:  INODE); 

procedure  TRAVERSECT:  TNODE); 
begin 

if  T7.LS0N  i  nil  then  TRAVERSE (T T . LSON ) ; 
N  : =  T  ;  suspend ; 

if  T7.RSON  i  nil  then  TRAVERSE (TT . RSON ) 
end ; 

beg  in 

TRAVERSE (ROOT ) ; 

N  : =  nil 

end ; 

coroutine  TRAV1  instance  of  TRAV; 
coroutine  TRAV2  instance  of  TRAV; 


Figure  6.2.  Coroutine  Class  and  Instance  Declarations 


7 .  Parameters  for  Coroutines 


Since  hierarchical  coroutines  must  resemble  procedures  it  is 
necessary  that  they  be  allowed  to  have  parameters.  In  providing 
a  parameter  mechanism  a  question  which  must  be  answered  is 
wnetner  or  not  a  resuming  (rather  than  initiating)  call  of  a 
coroutine  can  or  should  cause  the  coroutine’s  parameters  to  be 
rebound.  In  [9]  Hanson  and  Griswold  avoid  this  problem  by 
leaving  it  up  to  the  programmer  to  decide  whether  or  not  to 
rebind  parameters.  Other  coroutine  implementations  [5,22]  lack 
parameters  completely  and,  hence,  do  not  have  to  face  the  issue. 

That  the  answer  to  the  above  question  cannot  be  to  leave  the 
bindings  unchanged  is  illustrated  by  the  example  in  figure  7.1. 
If  "var"  (reference)  parameter  x  is  not  rebound  when  C  is 
resumed,  it  will  be  left  pointing  at  an  undefined  variable  and  in 
most  implementations  at  part  of  character  string  ch.  Thus,  the 
language  is  not  type  safe  or  safely  block  structured.  It  permits 
the  aliasing  or  e qui v al enc ing  (in  the  FORTRAN  sense)  of  variables 
of  possibly  different  types  residing  in  disjoint  procedures. 

Witnout  going  into  too  many  details  of  coroutine 
implementation,  consider  figure  7.2  wherein  we  illustrate  the 
situation  alluded  to  in  the  preceding  paragraph.  Coroutine  C  has 
its  activation  record  separate  from  the  run-time  stack  (e.g.  in 
the  heap  for  SIMULA)  leaving  room  in  the  stack  for  Q's  larger 
activation  record  to  replace  that  of  P  after  P  terminates  and  Q 
is  c al led . 


Coroutine  MAIN 

Coroutine  C(var  x  :  real); 

suspend ; 

• 

end ; 

Procedure  P; 

var  a  :  real; 

C C  a)  ; 

• 

end ; 

Procedure  Q; 

var  ch  :  array  [1..10J  of  char; 
b  :  real; 

CC  b)  ; 

• 

end ; 

beg  in 

P; 

Q; 

end 

Figure  7.1.  Illustration  of  the  Need  to  Rebind  Parameters 

In  this  quite  reasonable  implementation,  if  x  is  not  updated 
it  continues  to  point  to  the  storage  occupied  originally  by  a  and 
now  by  part  of  ch.  In  the  meantime  the  argument,  b,  is 
completely  ignored  and  may  as  well  have  been  left  out. 

Thus  not  only  is  x  liable  to  violate  rules  of  type  safety, 
but  it  is  impossible  to  transmit  new  parameters  to  an  already 
initiated  coroutine.  Of  course,  if  P  were  to  change  the  value  of 
the  argument  a  and  call  C  a  second  time,  this  new  value  would  be 
available  to  C,  but  communication  via  modification  of  reference 
arguments  is  scarcely  more  appealing  than  using  global  variables. 

In  addition,  what  if  x  were  a  value  parameter?  In  that 
case,  unless  it  is  rebound  it  could  never  be  changed  by  the 
caller.  Thus,  constants  could  not  be  used  as  arguments. 

We  conclude,  therefore,  that  failure  to  rebind  coroutine 
parameters  is  both  unsafe  and  overly  restrictive.  Let  us  now 
examine  the  consequences  of  the  alternative. 

With  coroutine  parameters  being  rebound  on  re-entry  the 
fragment  in  figure  7.1  produces  a  behaviour  similar  to  that 
illustrated  in  figure  7.3.  Now  x  is  rebound  (re-evaluated)  to 
reference  the  location  of  b  in  the  activation  record  of  procedure 
Q.  Not  only  is  there  now  no  type  violation  but  the  coroutine  is 
sensitive  to  changes  in  the  identity  of  actual  arguments. 
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Furthermore,  value  parameters  ean  also  be  changed,  whereas 
previously  they  could  only  be  used  to  supply  initial  values. 

The  dynamic  nesting  of  procedure  calls  within  coroutines 
creates  the  potential  for  further  ambiguity  in  interpreting  the 
binding  of  the  parameters  of  those  procedures.  The  seed  of 
uncertainty  is  sown  when  a  nested  procedure  executes  a  suspend 
instruction.  The  question  arises  when  execution  of  the  coroutine 
and,  hence,  the  nested  procedure  is  resumed.  How  are  the 
bindings  of  the  procedure's  parameters  affected? 

Two  answers  are  conceivable.  The  procedure  parameters  can 
retain  their  original  binding  or  they  can  be  rebound  in  the 
environment  of  the  resumed  coroutine.  Of  course  if  the  actual 
arguments  used  to  call  the  procedure  are  not  themselves 
parameters  of  the  coroutine  the  two  alternatives  give  the  same 
result.  Confusion  only  arises  if  a  procedure  argument  is  a 
coroutine  parameter. 


coroutine  MAIN; 

coroutine  C(var  x  :  real); 

procedure  R(var  y  :  real); 
suspend ; 

end;  { R } 

R(x); 

• 

end;  {C} 
procedure  P; 

var  a  :  real; 

C(  a) 

• 

end ;  {P  } 
procedure  Q; 

var  ch  :  array[1..10]  of  char; 
b  :  real; 

C (  b)  ; 

end;  {Q } 

begin 

P;  Q; 

end 

Figure  7.4.  Rebinding  Parameters  of  Nested  Procedures 


Consider  the  program  in  figure  7.4.  Coroutine  C  has  been 
expanded  from  what  was  shown  in  figure  7.1  to  reveal  a  nested 
procedure  R.  R,  not  C,  contains  the  suspend  statement  which 
causes  execution  of  C  to  be  suspended.  In  addition,  R  has  a 
reference  parameter  y  which  is  bound  to  x,  the  coroutine’s 
parameter . 


In  the  previous  section  we  concluded  that  x  must  be  rebound 
when  execution  of  C  is  resumed.  Figure  7.5  illustrates 
schematically  what  happens  when  only  this  is  done.  We  have  the 
same  problem  with  y  as  we  had  when  x  was  not  rebound.  This  time, 
however,  the  solution  is  not  as  simple.  It  is  easy  to  rebind  the 
coroutine  parameter  because  on  a  resuming  call  we  can  arrange  to 
re-execute  the  part  of  the  coroutine  prelude  which  initializes 
parameters.  This  cannot  be  done  for  nested  procedures  because 
they  are  only  invoked  once.  Their  execution  resumes  implicitly 
when  the  containing  coroutine  is  called. 


Figure  7.5.  y  Violates  Type  Safety  by  Retaining  Original  Binding 

(a)  x  and  y  reference  the  same  variable 

(b)  x  is  rebound  when  Q  calls  C  but  y  is  unchanged 
because  P  is  not  called  again. 


Figure  7.6(a)  shows  what  we  would  like  to  arrange  to  happen 
on  resuming  the  nested  procedure.  However,  to  do  this  we  would 
have  to  trace  through  all  active  calls  and  modify  all  appropriate 
parameters.  The  run-time  simulation  required  to  do  this  can  be 
quite  time-consuming  -  especially  if  R  is  actually  a  whole  series 
of  procedure  calls  which  pass  the  same  reference  parameter  down 
through  many  dynamic  levels.  With  such  an  expensive  resume 
mechanism,  coroutines  could  be  very  inefficient.  Consider,  for 
example,  a  case  where  R  is  a  recursive  procedure  which  descends 
through  many  activations  before  executing  a  suspend  statement 
(e.g.  the  previously  described  MERGE  procedure.) 

Another  solution  to  the  problem  of  rebinding  reference 
parameters  such  as  y  is  illustrated  in  figure  7.6(b).  Here 
nested  procedures  access  reference  arguments  of  the  coroutine 
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using  double  indirection.  Thus,  any  change  in  x  in  our  example 
is  automatically  reflected  in  y. 


Figure  7.6.  Two  Methods  of  Updating  Procedure  Parameters. 


This  second  "solution"  introduces  yet  another  problem. 
Procedure  var  parameters  are  not  always  bound  via  coroutine  var 
parameters  to  variables  outside  the  coroutine.  In  cases  where 
they  are  not  there  exists  no  intermediate  variable  through  which 
double  indirection  can  take  place.  For  example,  consider  the 
coroutine  in  figure  7.7. 


1 . 

coroutine  C(var  x  :  real); 

2. 

var  d  ,e  :  real ; 

procedure  R(var  y,z,w  real); 

3. 

4. 

• 

suspend ; 

5. 

• 

end ; 

6. 

begin 

• 

7. 

if  d  >  e  then  R(x,x,e) 

8. 

else  R (  x  ,d  , e ) 

9. 

end 

Figure  7.7.  A  Coroutine  in  which  Rebinding  is  Sometimes  Needed 


Figure  7.8  shows  schematic  binding  diagrams  for  the  state 
preceding  suspension  of  C  in  each  of  the  two  possible  cases  (the 
alternatives  of  the  conditional  statement  in  lines  7  and  3.)  In 
f  .8(a)  both  y  and  w  can  be  bound  via  double  indirection,  whereas 
in  7.8(b)  only  y  can  use  double  indirection.  Assuming  the  calls 
in  lines  7  and  8  are  the  only  places  where  R  is  called  we  refer 
to  y,z,  and  w  as  being  respectively  absolutely  rebindable, 
potentially  rebindable,  and  nonreb ind able .  More  formal 
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definitions  of  these  terms  follow. 


e 

A 


0 


e 

A 


0 


(  b)  R ( x ,d  ,e) 

Figure  7.8.  Binding  References  for  the  two  Calls  in  Figure  7.7 


Generally  speaking  a  rebindable  parameter  may  need  to  be 
rebound  when  some  coroutine  resumes  execution.  If  it  is 
guaranteed  to  always  require  rebinding,  then  double  indirection 
can  always  be  used  to  reference  its  corresponding  argument  and 
the  parameter  is  called  uniformly  rebindable.  If  it  needs 
rebinding  sometimes  but  not  always,  it  is  called  potentially 
rebindable.  Otherwise  it  is  nonrebindable. 

Definition : 

A  reference  parameter  y  of  a  procedure  P  is  said  to  be 
rebindable  if  and  only  if  both  of  the  following  conditions  are 
satisfied : 

1)  The  argument  corresponding  to  y  in  some  invocation  of  P  is 
either 

(  i)  a  reference  parameter  of  a  coroutine  whose  suspension 
could  be  accomplished  from  within  P, 

(ii)  or  itself  a  rebindable  parameter. 

2)  P  or  some  procedure  called  (directly  or  via  intermediate 
procedures)  by  P  may  execute  a  suspend  statement  which 
suspends  the  coroutine  to  which  y  is  bound. 

Definition: 

A  reference  parameter  y  of  procedure  P  is  said  to  be 
uniformly  rebindable  if  both  of  the  following  conditions  are 
sat isf ied : 

1)  The  argument  corresponding  to  y  in  each  and  ev ery  invocation 
of  P  is  either 


(i)  a  reference  parameter  of  any  coroutine  whose  suspension 
can  be  effected  from  within  P,  or 

(ii)  itself  a  uniformly  rebindable  parameter. 

2)  P  or  some  procedure  called  (directly  or  via  intermediate 
procedures)  by  P  may  execute  a  suspend  statement  which 
suspends  the  coroutine  to  which  y  is  bound. 

Definition: 

A  parameter  is  potentially  rebindable  if  it  is  rebindable 
but  not  uniformly  rebindable. 

Nonreb ind able  parameters  cause  no  problems  at  all,  so  we 
shall  not  discuss  them  any  further.  Uniformly  rebindable 

parameters  are  also  easy  to  deal  with.  When  they  are  originally 
bound,  they  are  made  to  reference  their  value  via  two  indirect 
reference  links.  The  code  using  these  parameters  must  always 
perform  a  second  indirect  reference  before  accessing  the  value. 
To  compile  the  code  this  way  it  is  necessary  to  identify  all 
uniformly  rebindable  parameters. 

Potentially  rebindable  parameters,  however,  cause 
complications.  When  they  are  bound,  the  calling  routine  can 
easily  set  up  the  requisite  double  indirection  if  the 

corresponding  argument  is  appropriate,  but  how  can  references  to 
these  parameters  be  compiled? 

On  some  calls  double  indirection  will  be  in  effect  and  on 
others  it  will  not.  Hence,  unless  we  compile  two  almost 
identical  versions  of  the  same  procedure,  we  must  include  a  run¬ 
time  test  with  each  case  of  the  parameter.  An  extra  indirect 
reference  will  be  performed  only  if  this  instance  of  the 
parameter  is  actually  rebindable.  This  test  can  be  made  using  a 
flag  set  by  the  caller.  This  flag  is  in  effect  an  extra 
(invisible)  parameter  which  is  used  by  the  run-time  system. 

Table  1  summarizes  all  possible  cases  for  parameter 
transmission.  In  practice  the  flag  (PARMFLAG)  need  only  be  set 
for  potentially  rebindable  parameters  because  its  value  can  be 
determined  statically  for  all  other  kinds  of  parameter. 

In  order  to  avoid  repeated  run-time  testing  of  each  PARMFLAG 
it  is  possible  to  confine  the  test  to  be  done  just  once  on  entry 
to  the  procedure.  Whenever  double  indirection  is  not  already 
provided  (PARMFLAG  =  "DIRECT")  a  hidden  local  memory  location  is 
used  to  provide  the  extra  level  of  indirection.  The  hidden 
location  is  set  to  point  to  the  argument  and  the  parameter  is 
changed  to  point  to  the  hidden  pointer.  Thus,  the  code  for 
referencing  all  rebindable  parameters  can  be  compiled  to  always 
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TABLE  1 

Parameter  Transmission 


Parameter  \ 

1 

non-rebind  able  * 

rebind  able 

1 

Argument  | 

1 

1 

1 

value  ! 

parameter  1 

or  variable  ! 

1 

PARM  <-  ADDR(ARG) 

P A RMF LAG <- "DIRECT" 

PARM  <-  A DDR (ARG) 

P A RMF LAG<- "DIRECT" 

1 

reference  ! 

parameter  of  1 

a  couroutine  \ 

1 

PARM  <-  ARG 

P A RMFLAG<- "DIRECT" 

PARM  <-  ADDR(ARG) 
PARMFLAG<- "INDIRECT 

1 

reference  | 

parameter  of  ! 

a  procedure  | 

1 

1 

PARM  <-  ARG 

P A RMF LAG<- "DIRECT" 

PARM  <-  ARG 
PARMFLAG<-A  RGFLAG 
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call  graphs  node  lists  will  be  no  longer  than  n2-n+1,  where  n  is 
the  total  number  of  coroutines  and  procedures,  so  this  is  an 
acceptable  approach  and  preferable  to  a  workpile  driven 
algorithm . 

In  order  to  completely  identify  rebindable  parameters 
(according  to  part  2  of  the  definitions)  we  need  to  know  which 
procedures  can  cause  the  suspension  of  each  coroutine.  If  the 
dynamic  suspension  rule  of  PISA  [17]  is  used  to  determine  the 
coroutine  affected  by  a  suspend  statement  the  acquisition  of  this 
information  requires  the  use  of  depth-first-search  (DFS)  [1,10] 
or  a  similar  algorithm.  With  the  static  rule  a  simple  scan  of 
the  textual  nesting  structure  will  suffice. 


8.  Coroutines  as  Functions 


It  is  also  possible  to  have  hierarchical  coroutines  appear 
to  their  callers  as  functions.  A  typical  application  of  a 
functional  coroutine  is  as  a  random  number  generator,  an  example 
of  which  is  given  in  figure  8.1. 


cofunction  RANDOMCSEED:  integer):  integer; 

const  M  =  mmmmm;  C  =  ccccc;  MAXINT  =  nnnnn; 

var  LAST :  integer ; 

begin 

LAST  :=  SEED; 
while  TRUE  do  begin 

LAST  :=  (LAST  *  M  +  C )  mod  MAXINT; 

RANDOM  :=  LAST; 
suspend 

end 

end 


Figure  3.1.  A  Function  Coroutine 


The  function  return  syntax  used  in  the  figure  was  chosen  to 
be  consistent  with  the  syntax  of  Pascal.  A  language  having 
PL/I-like  return  statements  could  replace  the  last  two  statements 
in  the  loop  with  " suspend(LAST ) " ,  which  is  analogous  to 
"return(LAST)". 

The  advantage  of  providing  functional  coroutines  is  that  it 
becomes  possible  to  avoid  the  use  of  reference  parameters  for 
returning  results  from  coroutines.  For  example,  the  traversal 
coroutines  can  be  turned  into  functions  as  shown  in  figure  3.2. 
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cofunction  TRAViCROOT:  7N0DE):  7NODE; 

procedure  TRAVERSECT:  7N0DE); 
beg  in 

if  TT.LSON  i  nil  then  TRAVERSE (T 7 . LSON ) ; 

TRAVi  :=  T; 
suspend ; 

if  T7.RSON  i  nil  then  TRAVERSE (T7 . RSON ) 
end ; 

beg  in 

TRAVERSE (ROOT ) ; 

TRAVi  :=  nil 

end 

Figure  3.2.  Traverse  Coroutine  as  a  Function 


It  is  advisable  to  impose  one  restriction  on  the  use  of 
functions.  Nested  function  procedures  should  not  be  allowed  to 
suspend  their  enclosing  coroutine.  The  motivation  for  this 
restriction  is  that  it  is  not  clear  what  meaning  to  attach  to  the 
act  of  suspending  a  function  but  not  then  transfering  control 
back  to  the  function  call.  Hence,  our  third  design  criterion 
makes  the  restriction  desirable.  Note,  however,  that  coroutine 
functions  do  not  have  this  problem. 


9_.  Storage  Management 


The  introduction  of  coroutines  into  a  language's  control 
structure  has  a  profound  effect  on  the  kind  of  storage  management 
possible  in  the  implementation  of  a  programming  language.  No 
longer  are  we  guaranteed  that  procedure  entries  and  exits  will  be 
performed  in  a  1 ast- in-f irst-out  order.  As  a  consequence,  a 
simple  run-time  stack  is  not  of  use  in  allocating  dynamic 
storage . 

Of  course,  FORTRAN,  which  does  not  need  dynamic  storage,  can 
handle  coroutines  quite  well  with  its  static  memory  allocation, 
but  it  is  not  interesting  because  it  lacks  recursive  procedures. 

At  the  other  end  of  the  spectrum,  SIMULA  67  C5]  allocates 
activation  records  in  a  garbage-collectable  heap.  Heap 
management  makes  no  assumptions  about  LIFO  or  any  other  behaviour 
of  allocations,  but  it  is  not  as  clean  and  fast  as  stack 
managemt  it.  Thus,  ix,  violates  our  principle  that  programmers  not 
needing  the  full  power  of  coroutines  not  be  penalized  by  their 
presence  in  the  language.  We  wish  our  implementation  to  perform 
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like  a  stack  for  programs  which  either  do  not  use  coroutines  or 
use  suitably  well  behaved  coroutines. 

Bobrow  and  Wegbreit  [2]  discuss  a  general  storage  management 
scheme  which  may  be  applied  to  implementing  backtracking  and 
multiprocessing  as  well  as  unstructured  coroutines  similar  to 
those  in  SL5.  This  scheme  reduces  to  stack  behaviour  for  simple 
programs  but  is  more  elaborate  than  what  is  needed  for  our 
restricted  form  of  coroutine. 

The  data  structure  which  can  be  used  for  maintaining 
coroutine  and  procedure  activation  records  combines  features  of 
both  a  stack  and  a  heap.  For  each  coroutine  there  exists  a 
separate  linked  stack  which,  if  there  is  only  one  coroutine 
(i.e.,  the  main  program) ,  will  also  be  contiguous  in  memory  and, 
thus,  be  a  positional  stack.  The  base  of  each  such  stack  is 
indicated  by  means  of  a  statically  allocated  descriptor 
associated  with  each  coroutine.  These  descriptors  also  describe 
the  textual  nesting  of  coroutines  by  means  of  a  set  of  pointers 
to  one  another,  and  they  contain  a  display  for  use  in  accessing 
the  variables  in  the  associated  stack.  The  length  of  each 
display  can  be  determined  at  compile  time  and  is  equal  to  the 
maximum  procedure/ block  nesting  depth  within  the  coroutine. 
Finally,  the  coroutine  descriptors  contain  flags  to  indicate  the 
state  of  the  coroutine. 

Figure  9.1  shows  a  typical  storage  structure  for  a  program 
consisting  of  two  coroutines  (one  nested  within  the  other)  and 
one  procedure  (called  by  the  outer  coroutine).  The  encloser  and 
invoker  of  the  outermost  coroutine  are  conceptually  the  operating 
system  but  might  be  represented  by  null  pointers.  The  first 
activation  record  in  each  list  (the  one  pointed  to  by  COR_ACT) 
belongs  to  the  coroutine;  subsequent  activation  records  describe 
procedure  environments.  The  meanings  of  all  the  fields  are  given 
in  Tables  2  and  3. 
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Coroutine  Descriptors  Activation  Records 
(static)  (dynamic) 


Figure  9.1.  Storage  Management  Data  Structures 


TABLE  2 


Fielus  of  the  Coroutine  Descriptor 


ENCLOSED 

ENCLOSER 

NEXT 

INVOKER 

INVOKED 

COR_ACT 

TOP_ACT 

RESUME 

ALLOCATED 

DISPLAY 


-  descriptor  of  first  coroutine  textually  enclosed  in 
this  coroutine 

-  descriptor  of  coroutine  in  which  this  coroutine  is 
declared 

-  descriptor  of  next  coroutine  declared  at  the  same 
textual  level  as  this  one 

-  descriptor  of  coroutine  which  called  this  coroutine 

descriptor  of  the  coroutine  called  by  this 
coroutine 

-  activation  record  for  this  coroutine  (base  of 
stack) 

-  top  of  activation  record  stack  (youngest  activation 
record ) 

address  for  resuming  execution  of  suspended 

coroutine 

-  flag:  true  if  coroutine  is  currently  activated 

pointers  to  currently  addressable  activation 
records  in  the  stacks  of  this  and  the  enclosing 
coroutines 


NOTE:  ENCLOSER,  ENCLOSED,  and  NEXT  are  set  at  compile  time  based 
on  the  static  structure  of  the  program  text.  INVOKER,  COR_ACT, 
TOP_ACT,  RESUME,  ALLOCATED,  and  DISPLAY  are  initialized  when  the 
coroutine  is  called,  and  INVOKED  is  set  when  the  coroutine  calls 
a  nested  or  sister  coroutine.  When  a  procedure  is  called  or 
returns  the  TOP_ACT  and  DISPLAY  fields  of  the  active  coroutine 
descriptor  are  updated. 
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TABLE  3 

Fields  of  the  Activation  Records 


Pa KM LI  ST 

ACT_LEN 

PRED 

D1SPLA Y_SA VE 

RETURN 
DATA  AREA 


-  parameter  list  (addresses  of  arguments) 

-  length  of  the  activation  record 

-  pointer  to  preceding  activation  record  (next 
lower  in  the  stack) 

-  save  area  for  current  lexic  level  of  display  of 
calling  program 

-  return  address  for  procedure  or  coroutine 

-  variable  storage 


In  Appendix  A  algorithms  are  given  describing  how  these  data 
structures  are  manipulated  during  procedure  and  coroutine  calls, 
entries,  and  exits.  We  have  not  accounted  for  space  which  may  be 
required  to  hold  temporary  values.  This  space  could  be  included 
in  tne  activation  records  (with  overlaying  used  to  reduce  the 
space  they  occupy)  or  it  could  be  allocated  on  a  separate 
temporary  stack  (which  may  also  require  some  help  in  dealing  with 
much  rarer  cases  of  non-LIFO  behaviour).  To  discuss  temporaries 
in  more  detail  would  tie  us  too  directly  to  an  implementation,  so 
we  shall  not  pursue  the  discussion  further  in  this  direction. 

The  most  significant  feature  of  these  data  management 
routines  is  that  they  reduce  to  stack  allocation  of  a 
conventional  kind  when  there  are  no  coroutines  being  suspended  or 
at  most  one  suspended  coroutine  at  a  time.  Parameter  lists  are 
necessarily  allocated  before  the  rest  of  the  activation  record, 
but  the  storage  allocation  routine  is  designed  to  respond  to 
successive  calls  with  adjacent  blocks  of  storage.  Only  in  the 
case  of  coroutine  resumption  is  the  new  parameter  list  not  at  the 
front  of  the  activation  record,  so  it  must  be  copied  into  the  now 
useless  original  parameter  list.  This  is  much  less  copying  than 
is  required  in  the  scheme  of  [2]  and  copying  is  never  carried  out 
if  the  "suspend"  statement  is  not  used. 

With  this  data  management  scheme,  procedure  entry  and  exit 
are  scarcely  more  expensive  than  with  non-coroutine  stack-based 
schemes.  The  only  extra  instructions  result  from  the  need  to 
maintain  each  coroutine’s  activation  record  stack.  That  is,  we 
need  to  set  PRED  and  TOP  ACT  each  time  we  enter  or  leave  a 


29 


procedure.  The  stack  will  never  become  fragmented  if  only 
procedures  are  used,  so  there  will  never  be  a  need  to  resort  to 
garbage  collection  on  the  activation  record  storage  area. 

Design  principle  1  in  Section  2  nas  been  extended  to  the 
implementation  level.  There  is  one  calling  sequence  which 
suffices  for  calling  procedures  or  coroutines  or  for  resuming 
coroutines.  Thus  external  procedures  or  coroutines  can  be  used 
with  impunity  and  a  procedure  can  be  replaced  with  a  coroutine  of 
the  same  name  (or  vice  versa)  without  there  being  a  need  to 
modify  the  calling  program  at  either  the  source  or  object  level. 
Furthermore,  the  calling  sequence  is  fast.  In  addition,  even  the 
implementation  of  "suspend"  can  be  made  to  be  quite  fast. 

The  coroutine  entry  code  can  be  somewhat  slower  than  a 
procedure  entry  because  it  must  copy  either  a  display  or  a 
parameter  list  as  well  as  set  various  fields  in  the  coroutine 
descriptor.  However,  the  action  which  is  potentially  the  slowest 
is  the  coroutine  exit.  The  deallocation  of  all  suspended 
activations  can  take  a  long  time  under  some  circumstances 
although  in  other  cases  it  may  not  even  be  necessary. 


10.  Conclusion 


This  report  has  outlined  a  first  attempt  at  a  complete  yet 
safe  design  of  a  coroutine  mechanism  to  be  incorporated  into  a 
high  level  programming  language.  We  have  captured  what  we 
consider  to  be  the  essential  properties  of  coroutines  (parameters 
and  preservation  of  environments)  while  discarding  those  features 
which  result  in  poor  programming  style. 

Some  improvements  in  the  design  are  still  worth 
investigating.  For  example,  it  might  be  worthwhile  to  remove  the 
restriction  that  coroutines  cannot  be  declared  within  procedures. 
As  long  as  the  static  rule  is  used  for  determining  which 
coroutine  is  affected  by  a  "suspend"  within  a  procedure,  the 
semantics  of  such  a  design  should  remain  clear.  However,  the 
storage  management  may  become  somewhat  more  complicated  and  less 
efficient.  Also,  perhaps  SIMULA67  style  dynamic  allocation  of 
identical  coroutines  can  be  included  to  deal  with  situations 
(such  as  an  n-way  tree  merge)  in  which  the  number  of  coroutines 
required  is  not  known  at  compile  time. 
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APPENDIX  A 
LINKAGE  CONVENTIONS 

Call 

1.  Allocate  storage  for  the  parameter  list  and  store  its  address 

in  register  R PA RMS. 

2.  Store  parameter  addresses  in  the  parameter  list. 

3.  Transfer  to  the  coroutine  or  procedure,  saving  the  return 

address  in  RETAD. 

4.  On  returning,  load  the  function  return  value  if  there  is  any. 

(N.B.  The  coroutine  or  procedure  will  free  the  parameter  list 
s torag  e . ) 


Coroutine  Prologue 

1.  Save  address  of  calling  coroutine’s  descriptor  in  INVOKER 

field  of  the  invoked  coroutine’s  descriptor. 

Save  address  of  called  coroutine's  descriptor  in  INVOKED 

field  of  caller's  descriptor. 

All  subsequent  references  to  a  coroutine  descriptor  refer  to 

the  callee. 

2.  If  ALLOCATED  flag  is  set  then 

using  the  coroutine's  activation  record  (C0R_ACT)  do 

(a)  save  the  new  return  address  (RETAD)  in  the  RETURN  field 
of  the  activation  record; 

(b)  store  value  parameters  via  indirect  reference  into  the 
activation  record; 

(c)  copy  parameter  list  (i.e.,  addresses)  into  the  activation 
record ; 

(d)  release  parameter  list  pointed  to  by  RPARMS; 

(e)  transfer  control  to  resume  address  (RESUME)  in  coroutine 
descriptor,  usingthe  DISPLAYin  thecoroutine  descriptor 
(Note  that  the  local  scope  is  referenced  by  T0P_ACT  as 
well  as  by  the  display.) 

3.  Otherwise  (initial  entry) 

(a)  set  ALLOCATED; 

(b)  allocate  remainder  of  activation  record  contiguously  with 
parameter  list; 

(c)  address  of  complete  activation  record  is  address  of  parm 
list  (RPARMS); 
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(ci)  initialize  activation  record:  LENGTH,  PRED,  value 

parameters ; 

(e)  save  return  address  (RETAD)  in  activation  record 

(RETURN) ; 

(f)  link  activation  record  onto  activation  record  stack  (set 
TOP_ACT  and  COR_ACT); 

(g)  initialize  DISPLAY  -  copy  first  t-1  entries  from 

ENCLOSER's  DISPLAY,  wheret  isthe  tex tualnesting  level 
of  the  called  coroutine; 

(h)  set  trap  for  illegal  recursive  call  (RESUME  <-  error 
routine) ; 

(i)  proceed  with  execution. 

(N.B.  Capitalized  words  refer  to  fields  in  coroutine  descriptors 
or  activation  records,  or  to  registers  (RETAD,  RPARMS). 


Coroutine  Suspend 

1.  If  active  routine  is  not  a  coroutine  then  load  address  of 

activation  record  of  enclosing  coroutine  into  the  DBASE 
reg is  ter . 

(N.B.  This  may  not  be  the  most  recently  called  coroutine,  so 
more  than  one  coroutine  may  be  suspended.) 

2.  Copy  result  parameters  out  via  coroutine’s  PARMLIST. 

3.  If  the  coroutine  is  a  function  then  store  its  return  value. 

4.  Transfer  control  to  coroutine's  return  address  (RETURN). 


Coroutine  Epilogue 
(termination  of  coroutines) 

1.  Copy  result  parameters  out  via  PARMLIST. 

2.  If  coroutine  is  a  function  then  store  its  return  value. 

3.  Deallocate  activation  records  of  this  coroutine  and  of  any 

coroutines  calledby  it, which  aresuspended  .  Thisshould  be 
done  in  LIFO  order  using  the  DEALLOC  procedure  (cf.) 

4.  Reset  ALLOCATED. 

5.  Transfer  control  to  the  coroutine’s  return  address  (RETURN). 
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1  . 

2. 

3. 

4  . 

5. 

6 . 


Procedure  Prologue 

Allocate  the  remainder  of  the  activation  record  in  storage 
contiguously  following  the  parameter  list. 

Set  DBASE  <-  RPARMS,  the  address  of  the  complete  parameter 

list. 

Add  the  new  activation  record  to  the  stack  by  setting  PRED  and 
TOP  ACT.  (PRED  <-  TOP  ACT  ;  TOP  ACT  <-  DBASE) 


Copy 

value  pa  ram 

et 

er s  in 

to 

Save 

DISPLAY ( t ) 

(o 

f  c  ur  r 

en 

new 

ac  t iv at  ion 

record 
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:ed  ur  e . 

Sa  v  e 

the  return 

ad 

dress 

(R 

activation  record. 


t  coroutine)  in  DISPLAY_SAVE  of 
where  tis  thetextual  levelof 


ETAD)  in  RETURN  field. 


the 

the 


Procedure  Epilogue 


1.  Copy  result  parameters  back  to  argument  variables.  Also  store 

function  result,  if  any. 

2.  Restore  DISPLAY ( t )  from  DISPLA Y_SAVE . 

3.  Restore  RETAD  (return  address)  from  RETURN. 

4.  Remove  activation  record  from  stack  (set  TOP  ACT  <-  PRED  and 

DBASE  <-  PRED). 


5.  Free  the  storage  held  by  the  activation  record.  (N.B.  Even 
if  the  procedure  had  called  a  coroutine  which  is  now 
suspended,  this  coroutine  must  remain  allocated  because  it 
may  be  resumed  by  anothercoroutine  orprocedure  enclosing 
the  terminating  procedure.  Such  a  situation  will  cause 
fragmentation  of  the  activation  record  stack.) 


6.  Transfer  control  to  address  in  RETAD. 
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Storage  Allocation  Procedures 


procedure  DEALLOCCvar  CBASE:  T  CODESC) ; 

var  ACT:  1  ACTREC; 
begin 

with  CBA5E7  do  begin 

if  INVOKED  i  NIL  then  DEALLOCC IN VOKED) ; 

ifT  •-  TOP  APT' 

whil e” ACT  7  COR_ACT  do  begin 
FREE ( ACT ) ; 

ACT  :=  PRED(ACT) 

end ; 

F  REE ( COR_ACT ) ; 

COR_ACT  :=  NIL;  TOP_ACT  :=  NIL 

end 

end 


Procedure  to  Deallocate  Activation  Records  in  LIFO 
Order.  This  permits  the  activation  record  storage  area 
to  grow  and  shrink  as  a  stack  in  many  programs  where 
suspends  are  used. 


procedure  FREE  (ACT:  TACTREC); 

{FREE  can  treat  pointers  to  ACTREC  as  indices  to  stack  array} 

begin 

if  TOP  =  ACT  +  ACTT. LENGTH  then  TOP  :=  ACT; 

{We  do  not  bother  to  maintain  a  "free  list"  of  available 
non-cont iguous  blocks,  but  instead  resort  to  the  use  of 
garbage  collection  if  and  when  the  stack  is  exhausted.} 

end 


Procedure  to  Free  One  Activation  Record 


function  ALLOC  (var  N:  integer):  1ACT_REC; 
begin 

if  TOP  +  N  >  STACKLEN  then  GARBAGE_COLLECT ; 
if  TOP  +  N  >  STACKLEN  then  STACK_0 VERFLOW 
else  begin 

ALLOC  :=  TOP; 

TOP  :=  TOP  +  N 

end 

end 


Function  used  to  allocate  contiguous  blocks  of  storage 


APPENDIX  B 


PASCAL  DESCRIPTION  OF  ADDRESSING  CONVENTIONS 


In  che  following  code  fragments 
indicated  significances.  All  but 
constants . 


these  variables  have  the 
C  and  P  are  compile-tirne 


C  =  pointer  to  the  current  coroutine  descriptor 
P  =  pointer  to  a  parameter  list 

t  =  textual  level  of  the  variable  or  parameter  being  accessed 
v  =  offset  of  a  variable  within  its  activation  record 
j,k  =  offsets  of  parameters  in  their  respective  parameter  lists 
np  =  number  of  parameters 

d  =  5  =  distance  of  start  of  DATA_AREA  from  end  of  parameter  list 
xVAL  =  one  of  IVAL,  RVAL,  or  BVAL 


Record  Declarations 


type  ADDRESS:  record  case  TAG:  (DIRECT,  INDIRECT)  of 

DIRECT:  ( VALPTR :  TVALUE); 

INDIRECT:  ( ADPTR :  TADDRESS) 
end ; 


VALUE:  record  case  VTYPE:  (VINT,  VREAL,  VBOOL)  of 
VINT:  (IVAL:  INTEGER); 

VREAL:  (RVAL:  REAL); 

VBOOL:  (BVAL:  BOOLEAN) 

end ; 


CODESC : 


record  {coroutine  descriptor  template) 

ENCLOSER, ENCLOSED, NEXT , IN VOKER , IN VOKE D: 
COR_ACT ,  TO  P_ACT : 

RESUME: 

ALLOCATED: 

DISPLAY:  array  [0..maxnest]  of  T 


T  CODESC 
TACTREC 
T  CODE ; 
BOOLEAN 
ACTREC 


> 

9 

9 


end ; 


ACTREC:  record  {activation 
PARMLIST: 
LENGTH: 

PRED: 

RETURN: 

DISPLAY  SAVE: 
DATA  AREA: 


record  template) 

array  [1..np]  of  ADDRESS; 

INTEGER; 

TACTREC; 

T  CODE ; 

TACTREC; 

array  [1. .datalen]  of  VALUE 
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Accessing  Values 

1.  variables,  value  parameters,  or  result  parameters 

CT . DISPLAY ( t) I .DATA_AREA( v) 

2.  non-rebind  able  reference  parameters 

CT . DISPLAY ( t) T . PARMLIST ( j) . VALPTRT .xVAL 

3.  uniformly  rebindable  reference  parameters 

CT . DISPLAY(t)T. PARMLIST (j) . ADPTRT .VALPTRT .xVAL 

4.  potentially  rebindable  reference  parameters 

with  CT . DISPLA Y( t) T . PARMLIST ( j )  do 

if  TAG  =  DIRECT  then  use  VALPTRT. xVAL 


else  use  ADPTRT .VALPTRT .xVAL 


end 


Passing  Parameters 

{  Allocate  a  parameter  list  containing  np  ADDRESSes.  } 

P  : r  ALLOC(np) ; 

1.  Argument  is  a  variable,  value  parameter,  or  result  parameter. 
( row  1  of  Table  1 ) 

PT(k) .TAG  : =  DIRECT; 

PT(k).VALPTR  :=  ADDRSUMC  CT . DISPLAY ( t)  ,  np  +  d  +  v); 
{ADDRSUM  adds  the  displacement  given  as  the  second 
argument  to  the  address  in  the  first  argument  and 
returns  the  VALPTR  part  of  an  ADDRESS  datatype.} 

2.  Argument  is  a  reference  parameter  (row  3  of  Table  1)  or 
the  parameter  is  not  rebindable  (column  1). 

PT(k)  :=  CT .DISPLAY(t) T .PARMLIST( j) ; 

{i.e.  Copy  the  parameter  in  its  entirety} 

3.  Argument  is  a  coroutine  reference  parameter  and  the  parameter 
of  the  callee  is  rebindable  (row  2,  column  2). 

PT(k) .TAG  : =  INDIRECT; 

PT(k) . ADPTR  :=  new(  DIRECT, 

CT . DISPLAY(t)T. PARMLIST (j)T. VALPTR  ); 
{i.e.  Create  an  indirect  reference.} 
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